Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 007 / tcp_ip.arc / HOWTO.DOC < prev next >

Wrap

Text File | 1987-09-22 | 73.1 KB | 1,551 lines

Getting Started with the KA9Q TCP/IP Networking Code by Brian Lloyd, WB6RQN V-870921 Copyright, 1987, Sirius Systems, Incorporated, all rights reserved. Permission is hereby granted to reproduce this documentation all or in part so long as the following conditions are met: 1. All reproductions must fully credit the author and Sirius Systems, Inc., as the source. 2. Copies of this document may not be used for any commercial purpose without the express written permission of Sirius Systems, Inc., 19200 Tilford Way, Germantown, MD, 20874. Introduction: Phil Karn, KA9Q, Bdale Garbee, N3EUA, Mike Chepponis, K3MC, and others now too numerous to mention, have constructed a very nice networking package for packet radio. Their documentation is clear, interesting, and informative. Unfortunately it is more of a reference than a tutorial and, as such, is not as useful to the first-time user. This document is an attempt to provide you with the information you need to get up and running right now! After it works you can go back and read all the other informative material and understand better what you did. Before we go any further I want to point out that NET and BM were written to further the art of amateur packet radio technology and many of the commands and suggestions are made with that in mind. If you are in an academic environment or are simply interested in the concepts of the Internet Protocol Suite (TCP/IP) and are not a radio amateur (ham), you can probably skip the section dealing with TNC's. Other areas dealing with packet radio are also pretty well marked so you can also take them with a grain of salt as well. Configuring Your TNC for Network Operation: There are now several choices for TNC's to be used with the TCP/IP network code. Versions of the Keep It Simple Stupid TNC interface software (KISS) are available for the TNC-2, the TNC-1, and the VADCG board and clones (Ashby), the Kantronics family of TNC's, and the AEA TNC's. Here are the different setup/configuration modes for the different TNC's: TNC-2: First step is to prepare your TNC-2 for use with TCP/IP. The standard firmware for the TNC-2 is not very computer friendly and, as such, is not very useful when it comes time to make your computer speak with other computers. To that end Mike Chepponis wrote the KISS (Keep It Simple Stupid) TNC code. There are two ROM versions for the TNC-2. The first is contained in a type 2764 or 27C64 EPROM. This version contains the KISS code in it. The second version is contained in a type 27256 or 27C256 EPROM and contains both the standard TAPR 1.1.3 TNC code and a loader that will permit you to download the KISS code into the TNC. Check the EPROM you have received and determine which type you have. If you are burning your own EPROMs you probably do not need these instructions. Open up your TNC and locate the ROM. It is in the socket labled "U23." Using a small nail file or screwdriver gently pry up the existing EPROM. Carefully press the new EPROM into place being sure that the orientation is the same. If you are installing the 2764 type of EPROM you will need to make a small modification to the TNC. There is a location on the board just above the first RAM socket labled JMP-6. Turn the board over and cut the trace joining the two pads. Solder a two-pin jumper header in place. When using a type 2764 the jumper at JMP-6 should be removed and installed when a type 27256 EPROM is being used. That should complete the hardware part of the installation. Attach your TNC to your PC using an RS-232C cable. You can use the same cable that you were using to connect your PC to your TNC. If you are doing this for the first time and are not sure about your cabling, a cable with just pins 2, 3, and 7 passed through is sufficient. Some PCs like to see the signals Clear To Send (CTS, pin 5), Data Set Ready (DSR, pin 6), and Data Carrier Detect (DCD, pin 8) asserted. You can set this up by jumpering pin 4 to 5, and pin 20 to pins 6 and 8 at the female DB-25 connector that goes to the PC. Now to verify that the TNC still works. Apply power to the TNC and turn it on. The STA, CON, and PWR LEDs should come on and the STA and CON lights should go out again about 1 second later. If you have the type 2764 EPROM with the KISS code in it one or both of the STA and CON LEDs will begin to flash. If the CON LED flashes you have 8Kb of RAM in the TNC. If the STA LED flashes you have 16Kb of RAM. If both LEDs flash you have 32 Kb of RAM. The flashing of the LEDs verifies the proper operation of the TNC. If you got the combined loader and TAPR version EPROM, checkout is a slightly different process. You can test your TNC-2 using two methods. The first method is to connect your TNC to a terminal program and send the character 'h' or 'H' to the TNC. The result should be the standard TNC startup message. Exit from the 1.1.3 mode of operation by issuing the reset command to the TNC. The second method involves downloading the KISS code to the TNC. Use the mode command to set the baud rate of the comm port to the proper value, e.g. it matches the DIP switch setting on the back of the TNC, and copy the file tnc2kiss.hex to the appropriate comm port. The following command sequence will serve to download the KISS code to the TNC: mode com1:4800 copy tnc2kiss.hex com1: If the download was successful the STA and/or CON LEDs will begin flashing as described in the previous paragraph. If the download is not successful check the cable from computer to TNC, check the baud rate on the TNC, and check to insure that the computer is indeed sending data to the TNC. Once this is done the TNC is ready to use with the NET program. NOTE: running KISS causes the stored parameters in the TNC, i.e. MYCALL, NEWMODE, TXDELAY, etc., to be destroyed. Every time you shift from KISS to TAPR modes you MUST reset the parameters. TNC-1 or Heath HD-4040: The firmware for the TNC-1 is available in either a downloadable version or a standalone version. I will describe only the standalone version here. Locate the ROM labled E000 and remove it. Insert the KISS PROM in its place making sure that you orient the prom in the same direction (failure to do so will result in smoked PROM). Connect your TNC-1 to your computer using an RS-232 cable. A cable that passes the signals from pins 2, 3, and 7 should be sufficient but just to be safe jumper pins 4 to 5, and pin 20 to pins 6 and 8 on the computer end (this is to insure that the signals CTS, DSR, and DCD are asserted at the computer). Since the TNC-1 has no switches for setting the baud rate to the computer the firmware has an autobaud routine to determine the opperating speed of the computer. Using a terminal program send several carriage return characters to the TNC-1 immediately following power-up. Start the net program and you should be running. AEA PK-232, PK-87, or new Heath TNC (PK-232 clone): If you have one of these boxes, congratulations! You do not have to change PROMS! KISS is already installed as a standard feature if you have a recent release of the firmware, 4-MAR-87 or later for the PK-232, or 21-JAN-87 or later for the PK-87, you have KISS in your TNC already. To make it work first insure that your computer can communicate with the TNC in standard packet mode. This will insure that the computer, TNC, cabling, and radio are all operating properly. [Please note that one of the commands "PACKET" is not valid on the PK-87 and will only elict a "Huh?" response. Please note that comments have been added to the commands. Do not type the information following the double dash or type the double dash itself.] Here is the sequence of commands that will turn on the KISS mode for the AEA products: AWLEN 8 -- insure it can speak 8 bit data PARITY 0 -- no parity RESTART -- warm reset; make the previous commands take effect PACKET -- PK-232 or Heath only TONE 3 -- PK-87 only START 0 -- start, stop, xon, xoff, xflow to disable software STOP 0 flow cont XON 0 XOFF 0 XFLOW off CONMODE trans -- pass through all characters HPOLL off -- disable host polling KISS on -- enable KISS version of host mode RAWHDLC on -- turn off AX25L2 (the protocol is now handled by the PC) PPERSIST on -- turn off DWAIT and enable p-persistence HOST on -- start KISS running The PK-87 or the PK-232 will remain in the KISS mode until you send a break (~200ms of spacing) or until you send the command character three times (^C ^C ^C) in quick succession. Beware! Some terminal emulators (like YAPP) will send a break signal when you exit from them. That will undo your work and cause all manner of confusion. The terminal program PROCOMM seems to work just fine. The TNC may also be switched back to ordinary AX.25 mode by issuing the following command from within NET.EXE: param ax0 FF Kantronics: Kantronics has recently begun to offer KISS on their products. It is the simplest of the commercial implementations of KISS to configure and use. First setup and operate your KAM, KPC-II, or KPC-4 for standard packet operation. This will insure that the computer, TNC, cabling, and radio are operating properly. Use your terminal program to send the following commands: ABAUD 4800 -- set the baudrate to whatever you will be using when net is running (set by the attach command) DWAIT 0 -- disable DWAIT PERSIST 50 -- enable persistence and set it to about 20% SLOTTIME 16 -- set the slot time to 160 ms KISS ON -- Enable KISS mode at the next reset PERM -- make the above command permanent so that KISS will be entered whenever the TNC is powered up RESET -- start KISS If you wish to have the the TNC revert back to ordinary AX.25 mode of operation you should omit the PERM command from the above sequence. That way the TNC will revert back to ordinary AX.25 mode when the power is removed and restored to the TNC. The TNC may be switched back to ordinary AX.25 mode by issuing the command: param ax0 FF This command will work even if the PERM command has been used to make KISS the default mode of operation. Installing and Configuring the Net Software: Create a directory called EXE and set that as the default directory. Use PKXARC to extract the files from EXE.ARC into the new directory. Should you not have PKXARC already run the program PKX35A35.EXE provided with the distribution. This program will create the extraction utility and its documentation. There are two programs that make up the network software: NET.EXE (the networking code) and BM.EXE (the mail program). Copy these programs from the EXE directory to the place on your hard disk where you keep command programs. If you are running on a floppy based system you should create a bootable floppy and copy these programs to the floppy. Test to make sure that everything is there by executing the programs. Type the command "net" and, if the installation of the network code was successful, the message "KA9Q internet protocol package" and the prompt "net>" will appear on the screen. This means that the network code is running and awaiting commands. Exit from the net code with the command "exit." Now run the command "bm." The screen should display the message "Bdale's Messy-DOS Mailer" and the prompt "Brian"> will appear. If all this has occurred, all is well so far. If you do not get this response from bm, do not be concerned. Try again after you have configured bm in the following steps. First step is to configure the mailer (BM). To make BM work properly you must create the following directories on your disk: \spool \spool\mail \spool\mqueue Copy the file SEQUENCE.SEQ to the \spool\mqueue directory. Copy the files HOSTS.NET and BM.RC to the root directory of the default drive used when net is running. If you are on a floppy based system you need to put BM.RC with NET.EXE, BM.EXE, AUTOEXEC.NET, HOSTS.NET, and AUTOEXEC.BAT in the root (\) directory (more on AUTOEXEC.NET later). HOSTS.NET You will need to edit the file HOSTS.NET to know about all the systems with which you will exchange mail. This is how net will translate the name into the IP address. Here is an example of some of the entries I have in my machine for other local TCP/IP stations: 44.96.0.2 WB2SEF 44.96.0.16 N8FJB 44.96.0.17 KA3LYQ Roel All this does is translate the symbolic name to the IP address, e.g. WB2SEF gets translated to 44.96.0.2 so that IP can route it to the proper network node. This saves you from having to remember lots of numbers. You may note that the last entry has two aliases, either of which may be used to specify the IP address 44.96.0.17. BM.RC Next edit the file BM.RC. This file lets the mail system know about local host name, user name, editor name, and the name of "punt to" system. Here are some example entries: host wb6rqn-pc.dc.ampr.us user brian edit emacs The edit entry should contain the name of your favorite editor, such as edlin (edlin is not your favorite editor?). This editor will be used to construct a mail message when you invoke that function of bm. You may use any DOS compatible editor just so long as it has the capability to prepare ascii files (be careful if you specify a word processor -- some word processors embed special characters in the file). Later on you can read the documents BM.DOC and SMTP.DOC to get more information. You at least have enough info to get your mailer running now. FTPUSERS Now you need to possibly modify the \FTPUSERS file to permit users to send and receive files from your system. The FTPUSERS file contains the information about users in the following format: user password \directory permission-code The 'user' entry is the user's name, 'password' is the password for that user, '\directory' is the directory to which the user will have access (all of the subdirectories too), and permission-code is a number between 0 and 7 that defines what the user may do. The permission-code is a bit-map where the three least significant bits each have a specific meaning. Here is a table: 1 - read and directory access 2 - create access 4 - overwrite and delete access The protection bits are added together to create the permission-code. For example 3 (1+2) permit the user to read files and create new files but not overwrite or delete and existing file. A permission-code of 7 (1+2+4) would permit full access. Here are some examples: guest * \public 3 brian xyzzy \ 7 In these examples guest may log in with any password and may copy files or create new files in the directory \public while user brian must log in with password xyzzy but will be granted full access, e.g. read, write, overwrite, and delete, to all files in the system. If you are running in a radio-based environment I would not give out the latter user/password combination because it will give anyone access to your entire disk. Also remember that the user/password combination are broadcast in-the-clear for anyone to read (if they have trace turned on). It is wise to segregate your radio-link users in a separate directory tree and not permit delete or overwrite access. That should prevent malicious mischief. Configuring NET and the AUTOEXEC.NET file: Now you need to configure and run net. Configuring net to run may be performed manually every time you start up NET.EXE but that gets old pretty fast. There are usually many commands that must be typed the same way every time net is started. Fortunately Phil thought of this and provided the AUTOEXEC.NET file. The intention here is to place all the commands that you always execute in a file to be read and executed by NET.EXE whenever you start up. To this end you will want to edit the file AUTOEXEC.NET prior to running NET.EXE. Just use a text editor to enter the commands into the file AUTOEXEC.NET as you would type them at the "net>" prompt. Setting the IP address: When NET.EXE first starts up you need to tell it about many things, i.e what comm ports you have, what your IP address is, what your host name is, what other systems you will communicate with, what services you wish to provide, etc. The first thing to do is to tell net who we are with the ipaddr, hostname, and mycall commands. Enter your ip address in dotted decimal notation enclosed in brackets or give the symbolic name from your HOSTS.NET file. Here is an example: ipaddr [44.96.0.1] The selection of an address is very important. If you are going to be part of a network you must have a unique address. Talk to the person in your area who is responsible for coordinating addresses. If you are not a part of the Internet and are just using this with your own computers, pick any address that suits you. Hostname: The hostname command is used to set the name of your system. This is displayed when someone initiates an FTP session with your system. Again here is an example: hostname wb6rqn-pc.dc.ampr.us This corresponds to my system in my local domain. For the purposes of amateur packet radio your callsign is probably sufficient. Mycall (packet radio only): Since I also run net on the air (amateur packet radio networking) I must specify my amateur call sign with the mycall command. Again, here is the entry from my AUTOEXEC.NET file: mycall WB6RQN-0 The callsign is entered in the same form that is used with the standard TAPR TNC software, e.g. the callsign is followed by the SSID field. If you are going to run TCP/IP on the air using the ax25 driver (described below with the attach command) the mycall entry MUST preceed the first attach command that uses the ax25 driver. Otherwise there is no required order for these commands. Attach command: The attach command tells net about your comm ports and in what mode the ports will operate. Currently four types of comm hardware are supported: standard PC async comm adaptors, the HAPN TNC board for the PC, the Eagle RS-232/2 card, and the 3Com Ethernet controller. Each of these devices has its own version of the attach command. Here is the attach command for an async adaptor card acting as COM1:. You would use this to attach your pc to a TNC running the KISS code: attach asy 0x3f8 4 ax25 ax0 1024 256 4800 This means attach an asynchronous adapter whose port address is 3F8 hex using interrupt line 4 (both standard for com1:), as an ax25 device (KISS TNC), using a buffer size of 1024 and a maximum transmission unit (the largest packet you are allowed to send) of 256 bytes, running at 4800 bauds. The name of this device will be ax0 (until you exit from net). This is probably a pretty good place to start. If you want to also do this on COM2, making you a dual-port or dual frequency switch, you would add the line: attach asy 0x2f8 3 ax25 ax1 1024 256 4800 If you are instead going to use COM2: to connect with another PC using a hardwired connection (some of us do have multiple PC's) you might want to use COM2: to connect to the other PC. We would want to use SLIP to do this so the attach command would be: attach asy 0x2f8 3 slip sl0 1024 576 4800 If you have an HAPN TNC card for your PC you will want to enter the following attach command: attach hapn 0x3f8 4 ax25 h0 1024 256 csma This tells net to use an HAPN board with the port address 3F8h and interrupt request line 4. The speed of the board is determined by the board so the software has no control over that function. The last parameter, listed as 'csma' in the example, may also take on the value 'full' for full duplex operation. Recently the Eagle RS-232/2 card has become available at very reasonable prices. This two-channel card generates HDLC frames directly and may be connected to a modem for direct packet radio operation without a TNC. Normally it would be connected to a Bell-202-type half-duplex asynchronous modem. The attach command for the Eagle board is almost identical to that of the standard async comm card. Here is an example: attach eagle 0x300 5 ax25 eg0 2048 256 1200 Two items must be as shown in the example: the mode must always be ax25 (not SLIP) and the media name must begin with 'eg' and end with a single digit. The first Eagle card must be called eg0 and the second must be called eg1. The Eagle card is hardwired for a base address of 0x300 and IRQ5. The use of IRQ5 conflicts with the disk controller on the PC/XT (no problem with the PC/AT). If you wish to use the Eagle card with a PC/XT or compatible you will need to locate the trace from pin 3 of the 74LS125 (U12) to B23 (IRQ5) on the edge connector. Cut this trace at the edge connector and reroute it to B4 (IRQ2) on the edge connector. This will eliminate the conflict and allow you to use IRQ2. If you happen to have more than one PC you may wish to connect them using an Ethernet. The net software supports the 3Com 3C500 or 3C501 boards for the PC. The command to attach this board is: attach 3c500 0x300 3 arpa ec0 5 1500 This tells net that there is a 3Com 3C500 board at I/O address 300h using interrupt request line 3 with the media name ec0. Net should reserve five buffers and the largest Ethernet packet may be 1500 bytes long. A word about the selection of the value for the maximum transmission unit. For standard TNC's and radios 256 is probably the largest value you should use. This insures compatibility with the rest of the AX.25 community and insures that you are legal if you are operating unattended (part 97 of the FCC regulations specifically mentions the AX.25 protocol in permitting unattended digital operation above 50 MHz). The smallest value you may use is 64. Performance improves with larger values IF you can get them to the other end without errors. I suggest you stick with 256 until you can run some experiments of your own. If you have a good transmission path and all the stations and gateways are attended, feel free to use larger values. It will result in improved performance (see the discussion of the mss and window parameters). Param command: If you are using a TNC running the KISS code (you probably are if you are operating amateur packet radio) you will need to set the parameters in the TNC. This is accomplished with the param command. There are five settable parameters in the kiss code. They are: 1. Transmitter keyup delay (TXD). This is how long the TNC will wait after keying the transmitter prior to beginning to send data. The proper value for this parameter is dependent on your configuration. This value is in 10's of milliseconds. Acceptable values range from 0 (0 ms) to FFh (2,550 ms or 2.55 seconds). 2. Persistence (p). This is the probability that the TNC will key your transmitter if a slot is found empty (the channel is free). Acceptable values range from 0 (p = 1/255 = 0.4%) to FFh (p = 255/255 = 100%). The default value is 40h (25%). The optimum value is somewhere close to 1/n where n is the number of users on the channel. 3. Slot time (ts). This is how long that the TNC will wait between samples of the channel. Acceptable values range from 0 (0 ms) to FFh (2,550 ms or 2.55 seconds). 4. Tail timer (tt). This is how long the TNC will keep the transmitter keyed after the last character has been transferred to the HDLC controller. This has become an outdated command since most of the TNC's now set this value automatically based on data rate. 5. Full Duplex. A zero value (the defalult value) means operate the TNC in half-duplex CSMA mode (listen before you transmit). A non-zero value means transmit whenever there is data to send. Let us assume that on the channel associated with ax0 that I have a radio that requires a transmit keyup delay of 200 ms, I want persistence to be 20% (p=0.2), and I want the slot time to be 160 ms. These are the values that we use in the DC area and make us "good neighbors" who do not "hog" the channel. I would enter the following commands: param ax0 1 14 param ax0 2 33 param ax0 3 10 Note that the parameters are always specified as hexadecimal values. Do not make the mistake of typing 100 thinking that you are entering the value one hundred. The command processor only looks at the last two digits so the result would be to enter a value of 00. NOTE: The 'param' command will be used for issuing other device-dependent commands as the need arises. Right now it is used only for setting the parameters for kiss TNC's and the speed of SLIP and AX25 links. Other versions of the 'param' command will be added as the need arises. Digipeat command (packet radio only): If you are currently an active digipeater in your area you can also make your system continue to be a digipeater for those poor souls unlucky enough to still be running ordinary AX.25. The command for this is: digipeat on Mail Gateway: The mail subsystem (SMTP) needs to know where to send mail should the destination be unknown to the sending system. This is handled by the gateway command as follows: gateway wa3pxx gateway [44.96.0.13] Should you try to send mail to a host that is not in your HOSTS.NET file the mailer will route the mail to the system specified in the gateway entry. This presumes that the gateway system is smart enough to figure out to whom the mail is addressed so that the mail can be forwarded. At this time the mailer is not "smart" enough to act as a mail forwarding node. This field is only here should you be lucky enough to have another computer accessable to you with a smart SMTP mailer. Any UNIX 4.2 or 4.3 BSD system has such a mailer. For packet radio enthusiasts another use for the gateway command is to send mail on to your local BBS gateway station. Bob Gibson, WA3PXX, has constructed a gateway program that will permit the transfer of mail from the WA7MBL BBS to SMTP and back again. By having your local BBS run DoubleDos with the WA7MBL BBS in one partition and NET in the other you can automatically move mail between the two domains. Construction of Routing Tables: Now you need to construct the routing table. This table is used by the IP to determine how to forward your packets. Each entry consists of two or three parts, the IP address of the destination, the link upon which it is to be forwarded, and the IP address of the next station in line if there can be more than one IP address on the link (used if the mode is ax25 and not used if the mode is slip). Here are three sample entries, one for a station more than one hop away via ax25 to be forwarded by 44.96.0.7, one for station one hop away on ax25, and one for a station on the other side of a slip link: route add [44.96.0.5] ax0 [44.96.0.7] route add [44.96.0.2] ax0 route add [44.96.0.12] sl0 route add n3ja ax0 The first string following the command 'route add' is the destination IP address. The second field, i.e. ax0 or sl0, is the media and must match up with one of your previous attach commands. The last field is the next station in the path if the destination is more than one hop away. This is an optional field and only needs to be used if the media is a broadcast media such as Ethernet or AX.25 and the destination is more than one hop away. Note that the address may be specified as either an IP address in dotted decimal notation enclosed in brackets or it may be a symbolic address from your hosts.net file. If you choose the latter technique you must enter the symbolic address precisely as it was entered in the hosts.net file, e.g. upper and lower case characters in the name are significant. If you are using an Eagle RS-232/2 board your media is named eg0 or eg1. There is still a problem because there are two ports on the board. In order to solve this problem you will need to add the letters 'a' or 'b' to the media name. For instance, if you have a single Eagle card your media names become 'eg0a' and 'eg0b' for the A and B ports of the card respectively. Remember, take the media name from the attach command and append either A or B to the end of the name to select the appropriate port. Here are some examples: route add [44.96.0.22] eg0a route add aj9x eg0b wb3ffv There are two other special types of route entries; the default entry and a cluster entry. Here is a default entry: route add default ax0 [44.96.0.99] This means that if the address does not match any entry in your table, route the packet to 44.96.0.99 via ax0. Hopefully the switch at 44.96.0.99 will be able to forward the packet to its destination. This generally works well if you are merely an end node (a leaf) in the network and all your traffic goes to a single gateway. Cluster Routing and its Associated Concepts: The other option for routing is cluster routing. It allows you to send blocks of addresses in a certain direction. This is useful if all the users in a given area have some common part to their IP addresses. Here is an explanation of cluster routing and addresses in general. The IP address is thirty-two (32) bits long. It is generally represented as four 8-bit numbers, with each number being written in decimal form. For example, my IP address is 44.96.0.1. This number can be represented as the hexadecimal value 2C600001 or 00101100011000000000000000000001 in binary. We can break this out as follows: decimal 44 96 0 1 hexadecimal 2C 60 00 01 binary 00101100 01100000 00000000 00000001 Normally when you make an entry in the routing table, all bits of the address are significant, e.g. an exact match is needed for the address to be recognized. On the other end there is the default route in which any address matches. Cluster routing falls somewhere between these two extremes. Cluster routing allows you to specify how much of the address is to be considered valid. In order to determine how many bits in the address are valid you enter the address in a special format: route add [44.96.0.64]/26 ax0 This means that only the first 26 bits of the address are to be considered significant. This is a form of wild card for the address. Here is that address in binary to show the mapping: 00101100 01100000 00000000 01?????? The question marks in the above address show the least significant six bits being "wild," or matching any corresponding bits in the address. Here are some examples: 44.96.0.67 00101100 01100000 00000000 01000111 (a match) 44.96.0.89 00101100 01100000 00000000 01011001 (a match) 44.96.0.01 00101100 01100000 00000000 00000001 (no match) This works because the routing process in the net code will, when presented with an address, search for an exactly matching entry. Failing to find that it will then look for an address that matches on the most significant 31 bits, then 30 bits, and so on. If presented with the address 44.96.0.67 IP would, after 6 tries, match the address to the example given above. By judiciously assigning addresses we can make the address aid us in routing the packets. The users within a LAN should have something in common in the high order part of the address so that we can use a single entry in the routing table to make things go in the proper direction. Here in the Washington DC area all addresses begin with 44.96.0. This identifies this general area and may be used to provide routing to us. Once the packet arrives in our general area cluster routing is then used to further route the packets to the appropriate area. In DC and the parts of Maryland immediately surrounding DC the low order byte ranges from 0 to 63. Northern Virginia users get numbers in the range of 64 to 127. The Baltimore users get 128 to 191 while the Harrisburg, PA, users get 192 to 255. The idea being that we can use the top two bits in the low order byte of the address to identify LANs within the address. That way the bits in the high order part of the address will get you into the general area, the next part of the address will get you to the proper LAN, and the least significant bits will get you to the proper host or user. Routing Loops and the Time To Live (TTL) Command: It is quite possible (and likely!) to make errors when setting up routing tables that will cause a routing loop to occur (a routing loop is a circular path that never reaches the intended destination). Imagine what would happen if two stations had their default routing pointing at each other like this: host 1 (44.96.0.1): route add default ax0 [44.96.0.2] host 2 (44.96.0.2); route add default ax0 [44.96.0.1] In this case a packet that got routed using the default route would bounce back and forth between the two stations forever. There is a command that can prevent this from going on forever: the Time-To-Live (ttl) command. Every IP packet has a ttl field in it that is decremented by 1 at every hop and decremented by 1 for every second it is in the network. Normally net sets the ttl field to 255. If you know that no host is more than 5 hops away you might issue the following command: ttl 5 This means that all packets from your host/station are sent with ttl set to an initial value of 5. These packets will now be discarded if they haven't reached their destination after 5 hops. This limits the traffic in the network should somebody inadvertantly create a routing loop. Using Digipeaters and the ARP Add Command (packet radio only): Since there may not be many TCP users in your area you may need to use a digipeater (or two) to reach the other users in your area. This is now possible by adding entries to the ARP (Address Resolution Protocol) tables. ARP serves to map IP addresses into Ethernet or AX25 address, whichever is appropriate to the media in use. ARP normally does its work automatically by directly conversing with the other station but it cannot do that if the other station is reachable only via a digipeater. In that case you must "hard-wire" an ARP table entry with the ARP ADD command. Before you can use the ARP ADD command you must know the path to the other station. Let us assume that the station with whom you wish to communicate is WA4OIE (Other Internet Experimenter) whose address is 44.96.0.247, but the only path available is via WB3PID (Poor Inefficient Digipeater). In this case you will use the following ARP ADD command: arp add [44.96.0.247] ax25 wa4oie wb3pbd From this point on packets sent over an AX25 link to address 44.96.0.247 will use the AX25 destination addres of WA4OIE with an intermediate digipeater address of WB3PBD. If you need to use more than one digipeater it is permissable. Just place the callsigns of the digipeaters sequentially following the destination AX.25 address. Window and Maximum Segment Sizes: The next information we want to include is some information used by TCP to determine how much data it can send at one time and how much data may be outstanding before it stops to wait for an ack from the other end. Here are the example values: mss 216 window 648 The parameter mss stands for maximum segment size and represents the largest single segment that TCP will send. Mss should be set as a function of the quality of the link over which you are running. Relatively error-free links should use larger values of mss. If you are running on amateur packet radio and wish to operate unattended you should probably limit this value to 216 (an mss of 216 will cause you to send AX.25 packets that are 256 bytes long. The net program now compares the mss value and the mtu values given in the attach command for the media being used. Since TCP and IP each have a 20 byte header (a total of 40 bytes), an mss of 216 corresponds to an mtu of 256. If you are using mixed mtu's, i.e. 256 for AX.25, 1500 for Ethernet, and 576 for SLIP, set the mss to correspond to the largest mtu you are using and let net adjust the mss downward for the media that are using smaller values for mtu. In any case window should always be a multiple of mss to prevent the transmission of "shortie" packets every once in a while. The 'window' parameter is how many bytes may be outstanding at any one time before you wait for an ack. If you have a pretty good link you can increase the value of mss. If window is larger than mss TCP will run as a sliding window protocol, e.g. continue to send packets while waiting for ACKs on previously sent packets. Since TCP uses selective reject (resend ONLY those segments that were damaged or lost) this is not a very expensive proposition. If you are running on a radio channel at 1200 bauds remember that a 1024 byte transmission will take seven seconds, a time that can make you unpopular if you have to share the frequency with AX.25 TNC's that can not adapt to the high channel utilization. In those cases it is probably better to reduce window and/or mss values. The above values will make you fit in reasonably with your other AX.25 neighbors. Remember that the efficiency of large packets and long transmissions are probably not worth having your neighbors so angry that they tie a rope between your coax and the bumper of a pickup truck so that they can non-surgically remove your station from your shack. One last point before we move on; the mss and window values that you set will be the ones that your TCP will ask the OTHER station to use. When the session is initially set up the two TCPs will exchange mss and window values. This permits stations to automatically adjust to the capabilities of the other station. For this reason it is best to get everyone in your LAN to use the same values. Starting the Servers: Next you need to decide what services you will provide to other users in the network. You must start the servers or others won't be able to make use of your system for mail or file transfers. You will simply be a switch for other users (in fact, for a switch on a hill that may be just what you want). You will still be able to initiate file transfers or telnet sessions but no one will be able to initiate one with you. Should you fail to start the servers anyone trying to access those services on your machine will just receive a "Closed, (reset)" message. For the sake of consistancy you will probably want to use the start command to enable the following services: start telnet start ftp start smtp start echo start discard Telnet is the terminal-to-host and terminal-to-terminal mode, ftp is the file transfer protocol, smtp is the mail system (simple mail transfer protocol), and echo is the echo server (it just sends back any packets it receives -- good for finding out if a switch is out there and running). The discard server simply throws away anything it receives. The echo and discard servers are generally used for testing a link. Running the network Start the networking program running by issuing the command "net." You should be rewarded by having the "net>" prompt appear on your screen. If you prepared AUTOEXEC.NET as described in the previous section then you don't need to issue any configuration commands. If you have not set up AUTOEXEC.NET you will want to read that section of the manual prior to proceeding with this section. Operating Modes: Net provides two modes of operation: command and session. In the command mode you are interacting with the command interpreter to permit you to establish sessions, retrieve status information, establish new routing table entries, etc. Please consider the commands you were required to enter in the autoexec.net file. All of those commands were directed at the command interpreter. You can tell that the net.exe command interpreter is waiting for input because it will present this prompt: net> The session mode is unique to the session with which you wish to communicate. TELNET (terminal-to-host and terminal-to-terminal) and FTP (the File Transfer Protocol) are the two types of sessions with which you may interact and each has its own sets of commands and operating modes. Before you get too carried away with trying things it is probably a good idea to read at least as far as the discussion on multiple sessions. That will explain how to start and use TELNET and FTP as well as how to keep straight all the activity from multiple users. Running TELNET: TELNET is used to provide terminal mode access to a host computer system but may also be used to have a terminal-to-terminal "chat" with another operator. There are three commands directly associated with the TELNET service: the 'telnet', the 'eol', and the 'echo' commands. The 'telnet' command: The 'telnet' command is used to establish a TELNET session with a remote TCP socket, usually the TELNET server on a remote host. To establish a TELNET session you would issue the 'telnet' command as follows: telnet wb2sef telnet [44.96.0.2] Both of these commands would establish a TELNET session with the TELNET server at WB2SEF because WB2SEF is defined in hosts.net as having the address 44.96.0.2. Note that we merely specified that we wished to establish a TELNET session and the TELNET client then connected us with the TELNET server which resides at TCP port address 23. There is an extended syntax for the 'telnet' command that will let you specify the port number at the remote host to which you wish to be connected. Here is an example of the extended syntax: telnet [44.96.0.2] 7 telnet wb2sef 9 In the first example TELNET is being asked to establish a session with port number 7, the echo server, at the host whose address is 44.96.0.2. The second example also is a request to connect to the host whose address is 44.96.0.2 but this time the connection is to be made to port number 9, the discard server. These two ports are regularly used for test purposes, the echo server echoing back everything it receives and the discard server discarding everything it receives. Once you have issued the 'telnet' command you will see the message "SYN sent" followed a short time later by the message "Established" (assuming that your destination was reachable). At this point you would be in communication with the TELNET server on the other end. If the remote host is a timesharing computer (possibly running UNIX) you would very shortly be presented with a login screen. You may consider your keyboard and screen to be directly connected to the remote computer at this point. On the other hand maybe you were attempting to establish a connection with another computer running the net code. In that case you would be in keyboard-to-screen communication with the operator at the remote host (assuming that he/she selected the new session as the current session; a subject that will be discussed later). Whatever you type will appear on the other screen and vice-versa. In addition to the 'telnet' command there are the 'eol' and 'echo' commands. The 'echo' command determines what the TELNET client will do if the remote host offers to echo characters (what we would consider full duplex). Here is the command syntax: echo accept [the default value] echo reject If the remote host is a timesharing computer you probably want it to echo your characters back to you rather than let your local TELNET client echo the characters. This permits you to use sophisticated screen-oriented programs without having your local echoing disrupt the screen display. On the other hand you may prefer to reject echoing in the case of a very slow network where having what you type appear on the screen several seconds later could be very annoying. Please note that the setting of this parameter has no effect when entering a TELNET session with another copy of NET since NET always refuses to echo characters. The 'eol' command is also used to adjust the keyboard functionality when remote echoing has been negotiated. It is used to select the appropriate end-of-line character to be sent when the operator presses the <ENTER> or <RETURN> key. Here are examples of the two options: eol standard [the default value] eol unix Should you set 'eol' to 'unix' and remote echoing is negotiated by the two systems, the <RETURN> or <ENTER> key will send an ASCII linefeed character rather than the carriage return character. Normally this will not be needed but some UNIX system demand this. Should the remote host not respond to your <RETURN> key you might want to try this option. To exit back to the command prompt from within a telnet session press the F10 key. The 'net>' prompt will appear. This does not close the TELNET session but merely suspends it. Incoming data addressed to your TELNET session will be saved until you re-enter the session (see the discussion of changing sessions that follows later). The last item of interest to the TELNET user is how to terminate a TELNET session. That is accomplished with the 'close' command. To close the session simply press the F10 key to return to the command prompt and enter the 'close' command. You should be rewarded with the sequence of messages: FIN wait 1 FIN wait 2 Time wait [followed by a delay period of about 30 seconds] Closed (Normal) File Transfer (FTP): The File Transfer Protocol (FTP) permits you to send and receive both text (ASCII) and binary (image) files. The FTP application accepts many commands that will permit you to create files, delete files, change directories, and copy files. This section will guide you through the most used FTP commands. Establishing a Session: To establish an FTP session with a remote host you use the 'ftp' command. To establish an FTP session with WB2SEF I would use one of the following commands: ftp wb2sef ftp [44.96.0.2] Both commands do the same thing because of the information contained in my HOSTS.NET file. After issuing one of the above commands you would see the usual 'SYN sent' and 'Established' messages. You would then be greeted by a message from the remote FTP server that looked something like this: 220 wb2sef-pc.dc.ampr.us (Fri Sep 18 17:57:23 1987) FTP Ready This message tells you that the remote FTP is ready to accept commands from you. FTP gives you no prompt so at this point you must understand that after issuing a command you will be notified of the command's completion but no further prompting for messages will occur. One thing to note is that when FTP sends you a message it will always be prefixed with a three-digit number. This is for the benefit of computer programs that may be driving the FTP system. The number is for the benefit of the computer and the text is for the benefit of the user. The first thing you will need to do is to log in to the remote host with your user ID and your password. Unless you have been given a specific user ID and password by someone at the remote host you will probably log in with the guest user ID and password. You will send the 'user' and 'pass' commands and the remote host will send the numbered messages. Here is an example: user guest 331 Enter password pass xyzzy 230 Logged in This exchange presumes that your user ID is "guest" and that your password is "xyzzy." If the user ID does not require a password you may or may not be prompted for the password. NET always prompts for the password whether it needs it or not. If the remote host is running NET and has in its FTPUSERS file an entry that uses an asterisk (*) for the password, any password will be accepted. If you enter either an invalid user ID or an invalid password the remote FTP will return the following message: 550 Permission denied Simply reenter the 'user' and 'pass' commands with the proper values and you will be logged in. You may also enter new 'user' and 'pass' commands at any time to change your user ID and hence your permissions as far as the remote host is concerned. Manipulating Directories on the Remote Host: When you log into the remote host you will be set in "your" directory (I put the word your in quotes because many people may be using that directory since many people may be allowed to log in concurrently with the same user ID). You can get a directory listing of files within that directory with the 'dir' command (just like DOS). What you will receive back from the remote host will be a standard DOS directory listing. If you would prefer a short listing, e.g. only the names of the files, you can use the 'ls' command. Both commands will accept wildcards so the following commands are all valid: dir ls *.* dir *.com ls test*.dat After issuing the command you will see the following sequence of responses from the remote host: 200 Port command okay 150 Opening data connection for LIST \dir . . Your directory listing will be displayed here . . Get completer, nnnn bytes received 226 File sent OK The end of the "150 Opening data connection ..." response will differ depending on the directory request you made. If you used the 'dir' command you would see the word "LIST." If you used the 'ls' command you would see the word "NLST." What followed the "LIST" or "NLST" would be the name of the directory you are listing. In addition to listing directories you can change the directory and query for the current directory. Let us assume that for your user ID (guest) your root directory is \public. Let us also assume that in public you would find the three subdirectories tcp, games, and utils. When you log in your directory is set to \public. Now you issue one of the following commands: cd tcp cd \public\tcp The result would be the same since you were already in directory \public. FTP would then send you the response: 257 "\public\tcp" is current directory You may use the 'cd' command to change directory to any subdirectory below your home directory in the same way that the DOS cd command will also allow you change directories. If you are not sure what directory you are in you may use the 'pwd' (print working directory) command. If we were to issue the command: pwd the remote FTP would then respond: 257 "\public\tcp" is current directory as if you had just changed directories. Now we get down to the meat of the matter: sending and receiving files. Prior to doing a file transfer you need to tell FTP what type of transfer to use. You have two choices: ASCII (text files) or Image (binary files). To select what type of transfer to do you use the 'type' command. Here are the two possibilities: type i type a The former will set all subsequent transfers to image mode for sending binary files. The latter will set all subsequent transfers to ASCII mode for sending or receiving text files. If you use the 'type' command by itself like: type FTP will respond with either the word "Image" or "Ascii," whichever is appropriate. If you do not specify a type of transfer FTP will use the default value "ASCII." Files transferred with type set to ASCII will have their newline sequence translated to that expected by the remote host. Files transferred with type set to image will have no translation performed at all. All bytes in the file will be transferred with no changes whatsoever. Once you select the type of transfer you desire you may then send or receive files. The 'put' and 'get' commands are used to send and receive files respectively. Let us assume that I have a file on my system in my current directory called "foo" and I want to transfer it to the remote host and have it placed in my current directory there. To do this I would use the following command: put foo FTP would then transfer file "foo" from the local to the remote system. You would be know the status of the transfer from the following sequence of messages: 200 Port command okay 150 Opening data connection for STOR foo Put complete, nnn bytes sent 226 File received OK Now let us fetch file "bar" from the remote system. Here is your command the the responses from FTP: get bar 200 Port command okay 150 Opening data connection for RETR bar Get complete, nnn bytes received 226 File sent OK Now it may not be convenient to have the file retain its filename when it is copied. Perhaps there is already a file with the same name at the destination and you do not wish to, or may not be permitted to, overwrite the file. In that case you would add the destination filename to the get or the put command as follows: put foo bar get \public\tcp\herfile herfile In the first example the local file "foo" would be copied to file "bar" on the remote system. In the second example the file "\public\tcp\herfile" would be copied to "herfile" on the remote system. The reason for doing it this way in the second example is to avoid having FTP try to create the file "\public\tcp\herfile" on the remote end. Perhaps there is no directory "\public" or "\public\tcp" or perhaps you are in an FTP session with a system that has completely different file naming conventions (remember that you may be communicating with systems other than PC's). You may at some point want to terminate a transfer that is currently in progress. The 'abort' command is used for this. There are no parameters on the abort command. Just type 'abort' and the current transfer will be aborted. When done using FTP use the command 'quit.' 'Quit' will get you the following message sequence: 221 Goodbye! Close wait Last ACK Closed (Normal) All of this indicates that FTP has properly terminated the session and returned you to the command interpreter. Multiple Sessions: One of the advantages of NET is that it permits you to establish many sessions concurrently. For instance, you could establish an FTP session with a host and then switch back to the command interpreter so that you could start another session. The nice thing about this is that it in no way interferes with any sessions that are already running. Your FTP session continues to transfer data even while you enter into a TELNET session with the same or a different host. Any screen output that arrives for a session that is not the currently selected session will be held until you again select that session. This prevents you from losing any output while you interact with another session or with the command interpreter. As mentioned, in order to start a new session (or issue any other type of command for that matter) you must be interacting with the command interpreter. To get to the command prompt you need only press F10. Once at the command prompt you can examine or select a new session using the 'session' command (abrievated 'se'). The session command when used by itself will give you a list of all the currently open session. Here are two examples: session se The result will be a display similar to the following: # TCB Type State Remote socket 0 c7a8 Telnet Established w3fws:23 *1 c434 FTP Established [44.96.0.13]:21 The first field (#) is the session number. The asterisk (*) identifies the current session. TCB is the TCP Control Block associated with this session (TCB is explained in detail as part of the tcpstat command later in this document). The Type field identifies the session as either an FTP or a TELNET session. The state field indicates the state of the "connection" as far as this session is concerned. A value of SYN Sent indicates that the "connection" is in the process of being constructed. A value of Established indicates that the "connection" and therefore the session is open and ready to transfer information. Values of FIN Wait 1, FIN Wait 2, or Time Wait indicate that the connection is being closed. The last field, Remote Socket, identifies the host and port with whom the session was initiated. Once you start a session it becomes your current session unless you close it or switch to another session. To get back to a session from the 'net>' prompt all you need to do is press the <RETURN> or <ENTER> key. If you happened to close the current session there will be no current session. In that case pressing <RETURN> or <ENTER> will have no effect. You will need to explicitly select a new session with the session command. If you follow the session command with a number, the session command will make the session whose number was specified, the current session and then turn control of the keyboard and screen over to that session. Here are two examples: session 0 se 0 Both of these examples change the current session to session 0. At that point you will be interacting with the desired session. As mentioned in the section on the 'telnet' command you close a session by making that session the current one and then issuing the 'close' command at the 'net>' prompt. This will work for both FTP and TELNET sessions. While this is the only way to close a TELNET session, it is neither the only nor the most desireable way to close an FTP session. Last of all you may need to abort a session or an open socket. This may occur when you have a session with another host and that host goes away for whatever reason (power failure, hardware failure, link failure, etc.). In that case you must resort to the 'reset' command. The 'reset' command is a way to force TCP to close a particular socket without having to go through the normal closing sequence. The command format is the command 'reset' followed by a TCB number. Here is an example: reset c7a8 This example would force TCP to close the socket associated with the session with 44.96.0.13 and hence close that session. It would give no indication to the other end that the socket had been closed. The only indication that the other end would receive would be to receive a reset instead of an ACK packet the next time the remote end sent a packet of data. Status Monitoring and Other Commands: There are quite a few commands in net.exe. Many of them were explained in conjunction with the installation instructions and, in fact, have little use beyond initialization. Commands in this catagory include: ipaddr-----setting your IP address mycall-----setting your AX.25 link address ttl--------initial time-to-live field for IP packets attach-----starting a driver for a particular hardware device mss--------setting the maximum size for a TCP segment (packet) window-----setting the maximum number of un-acked bytes digipeat---enable/disable AX.25 digipeating hostname---set the name for your system (used by FTP) On the other hand there are quite a few commands that you will be using extensively. Let's start by covering the status commands. Getting Status Information: IPSTAT The first of the status commands is 'ipstat' and may be abbrieviated 'ips'. This returns information about the status of IP packets that have passed through your system: e.g. originated, received, or passed through (switched). The format for the ipstat response looks like this: total 973 runt 0 len err 0 vers err 0 chksum err 5 badproto 0 The 'total' field (973 in this case) identifies the number of IP datagrams that have passed through your system. The next field, 'runt', identifies the number of packets that were below minimum acceptable size. 'Len err' identifies the number of packets with length errors. 'Vers err' identifies packets that came from a system running a version of IP that is incompatible with the one that you are running (unlikely to occur unless the Internet adopts a new standard for IP). 'Chksum err' is the number of packets that arrived with a checksum error on the IP header (these packets will be discarded because the system has no way of knowing if any of the information is valid). 'Badproto' identifies the number of packets that arrived with the protocol identifier set to an upper layer protocol (ULP) that is not either TCP or UDP (the only two ULP's that are currently supported in net.exe). Of all these possible errors you are likely to see only the runt, len err, and chksum err fields increment. Version and bad protocol errors can only occur if you are communicating with a system that supports a different version or a different set of ULP's. This is unlikely to happen. TCPSTAT Another often used command is the tcpstat command. Tcpstat returns a great deal of information on the current status of your TCP "connections." Upon entering the command 'tcpstat' (abrieviated 't') the system will print a General status on the TCP activity and an abrieviated display on the status of each TCP session. The top line looks like this: Conout 5 Conin 17 Reset out 2 Runt 0 Checksum err 1 bdcsts 0 'Conout' is the number of TCP outgoing "connections" that have originated at your system while 'conin' is the number of incoming "connections" that have been made with your system. 'Reset out' is the number of resets that were sent to remote systems (this would happen if a remote system attempted to send data to a socket that had been closed). The 'Runt' field is the number of undersized packets that were received. The 'Checksum err' field is the number of TCP segments that were discarded because the segment failed the TCP checksum check (IP checksums only the packet header while TCP applies a checksum test to the entire TCP segment including header). The last field indicates the number of broadcast messages that have been received. Following the header line a table is presented, one line per socket. The headings appear as follows: &TCB Rcv-Q Snd-Q Local Socket Remote Socket State f784 17 0 44.96.0.1:1001 44.96.0.2:23 Established eb30 0 0 44.96.0.1:23 0.0.0.0:0 Listen (server) In the above example there are two open sockets. The first, associated with the TCP Control Block (TCB) at address f784, is a TELNET (terminal-to-terminal or terminal-to-host) session with the system whose address is 44.96.0.2. The second socket, described by the TCB at location eb30, is a passive open that exists to accept incoming TELNET connections. Now for a more comprehensive description of the fields. The TCB is the TCP control block. The number, in hex, is the address of the TCB in memory and serves to identify a particular open socket. Rcv-Q is the number of octets (8-bit things that we normally call bytes) that have been received and are waiting to be processed (this is one way to tell if you have received information from another station if you are involved in more than one TELNET or FTP session). The next two fields, Local Socket and Remote Socket, make up the identification of the connection as far as TCP is concerned. The first part of a socket number is the IP address. The second part of the socket number, the part following the colon, is the port number. There are many "standard" port numbers in use. Here are some of the more common: Port Application 7 Echo server 9 Discard server 20 FTP server data port 21 FTP server command port 23 TELNET server 25 SMTP server You may see other port numbers used such as 1001, 1002, etc. These are temporary ports that are used to form a unique connection (TCP identifies a connection by combining the remote and local socket address in order to guarantee uniqueness). Since no two systems have the same network address the combination of local socket (address + port) and remote socket forms a unique combination. This is how the TCP on both ends of a "connection" identifies that connection. It is possible to get even more information about a specific socket by adding the TCB address to the end of the tcpstat command like this: tcbstat f784 This will return the detailed TCP status information about the socket that is described by the TCB at address f784 (you get this address from the tcpstat command without a parameter). Here is the sample format: Local: 44.96.0.1:1001 Remote: 44.96.0.2:23 State: Established Init Seq Unack Next WL1 WL2 Wind MSS Queue Total Send: 5367e0 Recv: 593870 Retry 0 Timer stopped Smoothed round trip time 4687 ms The 'Init Seq', 'Unack', 'Next', 'WL1', and 'WL2' fields have to do with the sliding window nature of TCP. Continuous monitoring of these fields can give you a good idea of the performance of the network in terms of the number of packets lost. The 'Wind' field is the number of bytes that the channel can 'hold' at any one time. Whenever a TCP segment is transmitted the window 'closes' by the number of bytes in that segment. The receipt of an appropriate ACK can make the window open up (not all ACKs will make the window open because TCP permits receipt of segments out of order). Should the window close completely the sending station will then wait for an ACK so that it may begin sending again. NOTE: A good understanding of sliding window protocols is required to make use of the information presented in these particular fields and a complete explanation is beyond the scope of this document. See RFC-793 or MIL-1778 for more details on the specific sliding window algorithms used in TCP. The 'MSS' field displays the maximum segment size; the maximum number of bytes that may be sent as a single TCP segment (packet). Both the maximum window size and MSS are "negotiated" by the TCPs running in the two communicating system. Essentially this means that the two ends "agree" on the best values to use for these parameters. When you set a value for window size and a value for MSS in your machine, those values are communicated to the remote end when a socket is opened. That allows the remote end to know how much information you are prepared to accept and to prevent the remote end from sending you too much information. Remember, the values for window and MSS that you set on your system will be the values that the other station will use when sending to you. Also remember that the two ends may set different values and still work effectively. As an aside, you are permitted to change the value of MSS or WINDOW while the net program is running. On the other hand, changing the value of MSS or WINDOW after a socket has been opened will have no effect on any currently open sockets. Open sockets will continue to use the value for MSS that they negotiated when the socket was opened. The changed values will be used when TCP opens a new socket. The Queue field indicates how many bytes of data are waiting at a particular socket. In the case of the send queue this field indicates the number of bytes transmitted but not yet acknowledged. During SMTP and FTP sessions it is not unusual to see this value equal to the window size. In the case of the receive queue the value indicates the number of bytes that have been received but have not been "picked-up" by the application. The Total field indicates the number of bytes that have been received or transmitted on a socket since the socket was opened. This information is very useful during an FTP session because it will tell you the total number of bytes transferred on the file (FTP opens a new data socket for every transfer, closing the socket when the transfer is complete). If you know the size of the file ahead of time you can use this information to determine how much of the file has reached the receiving end -- nice information to know when doing a long file transfer over a slow or unreliable link. The next field is the retry counter. If a segment is not acknowledged within an appropriate period TCP will retransmit that segement because it will assume that the segment was lost somewhere in the network. Each time it retransmits a segment the 'Retry' counter is incremented. TCP never gives up sending data. It does 'back off' and send segments less and less frequently in order to reduce network loading. The next field is the 'Timer' field. It displays the status of the timer for this particular socket. If TCP is waiting for an acknowledgement to an outstanding segment there will be a time displayed in this field. If there are no outstanding segments the word "stopped" will indicate that the timer is not running. The last field, 'round trip time', is a very interesting piece of information. It is the amount of time that TCP has determined that it takes for an outgoing segment to arrive at its destination and for its acknowledgement to return. This value is used to detwrmine the proper setting for the retry timer thus allowing TCP to adapt to the changing conditions of the underlying network and to prevent the network from being flooded by unnecessary retransmissions. The tcpstat command is probably the most-used command in the net program. Don't be afraid of it, use it! You may not understand all the fields but you will quickly pick up what is important and what you can ignore. Experiment with it so that you understand it better. It is a key to pinpointing network performance problems. UDPSTAT The next status command of interest is 'udpstat,' used for getting status information about information that has been received for the User Datagram Protocol (UDP) ULP. This command may be abbreviated 'u.' When an application makes use of the UDP transport service it opens a UDP socket. The udpstat command will display the status of the transport service and of each of the open sockets. Here is an example of the output of a udpstat command: sent 51 rcvd 50 bdcsts 0 cksum err 0 Unknown Socket 9 &UCB Rcv-Q Local Socket ff38 293 44.96.0.1:3 In this example the 'sent' and 'rcvd' fields indicate how many UDP datagrams have been sent and received respectively. The 'bdcsts' field identifies the number of broadcast datagrams that have been received. The 'cksum err' field indicates how many datagrams have been received with errors while the 'Unknown Socket' field shows the number of datagrams that have been received that were addressed to unknown (unopened) sockets. Following the general information is the specific information about all of the currently open sockets. Each open socket is identified by the address of its UDP Control Block (&UCB). Following that is the number of bytes that have been received and placed on the receive queue (Rcv-Q). Last comes the actual socket identifier consisting of the IP address concatenated with the port number. Other Status Commands: This section will be added later. Other Useful Commands: This section will be added later. BM -- Sending and Receiving Mail This section will be added later. Running NET and BM Concurrently In order to get the greatest use out of NET it is important to have it running all the time. The problem with that is that DOS is not a multitasking operating system. It is very frustrating to have to start and stop NET every time you want to do something else. There is a solution: DoubleDos. The DoubleDos package from SoftLogic Solutions, Inc, solves this problem nicely. It permits you to split your memory into two partitions and allow each program to operate as if it had its own PC. Phil Karn wrote NET with DoubleDOS in mind and even included the necessary code in NET so that it can effectively reside with other programs without performance penalties to either NET or the other program running in the other partition. This will also allow you to send and receive mail with BM while NET is still running. That way you will not have to exit from NET everytime you want to prepare a mail message or read mail that has arrived. The first step in using NET with DoubleDOS is to install DoubleDOS according to the instructions. Part of installing DoubleDOS is to modify the file \DDCONFIG.SYS for your environment. Many things can be changed in DDCONFIG.SYS but two are important to NET: size and program to load in the bottom partition. When you edit DDCONFIG.SYS you will find a field named 'bottom size' and a field named 'bottom program.' If you want NET to be started automatically when you start DoubleDOS enter the following in DDCONFIG.SYS: bottom program = \net.exe DoubleDOS will normally split the available memory in half. This is not the best solution because we know how much memory NET needs and we can then make sure that all of the rest of the available memory is available for the other partition. NET itself needs about 128 Kb of memory. In addition, NET needs COMMAND.COM also loaded in its partition. For this reason you will probably want to allocate about 175 Kb to the bottom partition where NET will run. Let us assume that you want to have both DoubleDOS and NET start when your system boots (just what you want after a power hit). Add the following entry to your AUTOEXEC.BAT file: \doubledo That will cause DoubleDOS to start and DoubleDOS will automatically start NET.